-
Notifications
You must be signed in to change notification settings - Fork 154
Add a dynptr type for skb metadata for TC BPF #9483
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Upstream branch: 0786654 |
c210f22
to
2530e45
Compare
Upstream branch: dc0fe95 |
4c2ed74
to
50187ba
Compare
2530e45
to
61c9cef
Compare
Upstream branch: c80d797 |
50187ba
to
606c693
Compare
61c9cef
to
715d6cb
Compare
Upstream branch: 3ec8560 |
606c693
to
cc07ae4
Compare
715d6cb
to
506c27a
Compare
Upstream branch: 1274163 |
cc07ae4
to
caafe6b
Compare
506c27a
to
76c716d
Compare
Upstream branch: d87fdb1 |
caafe6b
to
f324853
Compare
76c716d
to
f3b4b37
Compare
Add a dynptr type, similar to skb dynptr, but for the skb metadata access. The dynptr provides an alternative to __sk_buff->data_meta for accessing the custom metadata area allocated using the bpf_xdp_adjust_meta() helper. More importantly, it abstracts away the fact where the storage for the custom metadata lives, which opens up the way to persist the metadata by relocating it as the skb travels through the network stack layers. Writes to skb metadata invalidate any existing skb payload and metadata slices. While this is more restrictive that needed at the moment, it leaves the door open to reallocating the metadata on writes, and should be only a minor inconvenience to the users. Only the program types which can access __sk_buff->data_meta today are allowed to create a dynptr for skb metadata at the moment. We need to modify the network stack to persist the metadata across layers before opening up access to other BPF hooks. Once more BPF hooks gain access to skb_meta dynptr, we will also need to add a read-only variant of the helper similar to bpf_dynptr_from_skb_rdonly. skb_meta dynptr ops are stubbed out and implemented by subsequent changes. Reviewed-by: Jesse Brandeburg <[email protected]> Signed-off-by: Jakub Sitnicki <[email protected]>
Now that we can create a dynptr to skb metadata, make reads to the metadata area possible with bpf_dynptr_read() or through a bpf_dynptr_slice(), and make writes to the metadata area possible with bpf_dynptr_write() or through a bpf_dynptr_slice_rdwr(). Note that for cloned skbs which share data with the original, we limit the skb metadata dynptr to be read-only since we don't unclone on a bpf_dynptr_write to metadata. Signed-off-by: Jakub Sitnicki <[email protected]>
dynptr for skb metadata behaves the same way as the dynptr for skb data with one exception - writes to skb_meta dynptr don't invalidate existing skb and skb_meta slices. Duplicate those the skb dynptr tests which we can, since bpf_dynptr_from_skb_meta kfunc can be called only from TC BPF, to cover the skb_meta dynptr verifier checks. Also add a couple of new tests (skb_data_valid_*) to ensure we don't invalidate the slices in the mentioned case, which are specific to skb_meta dynptr. Reviewed-by: Jesse Brandeburg <[email protected]> Signed-off-by: Jakub Sitnicki <[email protected]>
Upstream branch: dbe99ea |
Prepare for parametrizing the xdp_context tests. The assert_test_result helper doesn't need the whole skeleton. Pass just what it needs. Acked-by: Eduard Zingerman <[email protected]> Reviewed-by: Jesse Brandeburg <[email protected]> Signed-off-by: Jakub Sitnicki <[email protected]>
We want to add more test cases to cover different ways to access the metadata area. Prepare for it. Pull up the skeleton management. Acked-by: Eduard Zingerman <[email protected]> Reviewed-by: Jesse Brandeburg <[email protected]> Signed-off-by: Jakub Sitnicki <[email protected]>
Exercise reading from SKB metadata area in two new ways: 1. indirectly, with bpf_dynptr_read(), and 2. directly, with bpf_dynptr_slice(). Acked-by: Eduard Zingerman <[email protected]> Reviewed-by: Jesse Brandeburg <[email protected]> Signed-off-by: Jakub Sitnicki <[email protected]>
Add tests what exercise writes to skb metadata in two ways: 1. indirectly, using bpf_dynptr_write helper, 2. directly, using a read-write dynptr slice. Acked-by: Eduard Zingerman <[email protected]> Reviewed-by: Jesse Brandeburg <[email protected]> Signed-off-by: Jakub Sitnicki <[email protected]>
Exercise r/w access to skb metadata through an offset-adjusted dynptr, read/write helper with an offset argument, and a slice starting at an offset. Also check for the expected errors when the offset is out of bounds. Acked-by: Eduard Zingerman <[email protected]> Reviewed-by: Jesse Brandeburg <[email protected]> Signed-off-by: Jakub Sitnicki <[email protected]>
Demonstrate that, when processing an skb clone, the metadata gets truncated if the program contains a direct write to either the payload or the metadata, due to an implicit unclone in the prologue, and otherwise the dynptr to the metadata is limited to being read-only. Signed-off-by: Jakub Sitnicki <[email protected]>
f324853
to
387d7d7
Compare
f3b4b37
to
bf66d41
Compare
At least one diff in series https://patchwork.kernel.org/project/netdevbpf/list/?series=991429 irrelevant now. Closing PR. |
Pull request for series with
subject: Add a dynptr type for skb metadata for TC BPF
version: 7
url: https://patchwork.kernel.org/project/netdevbpf/list/?series=991429